Interaction-Oriented Software Engineering: Concepts and Principles

ion refers to the level of the concepts used in a specification. The ideal abstraction is sufficiently high-level to hide details and reduce complexity, yet sufficiently low-level to support drawing the necessary conclusions. Tropos and i* offer high-level abstractions such as goals, capabilities, and goal dependencies. Sommerville et al. [2009] apply high-level notions of responsibility and delegation to requirements modeling. Using high-level abstractions places requirements away from low-level notions such as tasks, plans, and state machines. In contrast, IOSE emphasizes abstractions that capture the meaning of an interaction. Explicit Social Meaning Make all social expectations explicit in the system specification. The meanings of individual communications must be explicitly formalized in terms of what they count as in the society being designed. In general, the meaning involves the creation or other manipulation of the commitments among the parties involved. Example. Table I specifies the message meanings in an appointment scheduling protocol. Benefit. Explicit social meaning promotes loose coupling. As Figure 4 illustrates, the meaning captures how the principals’ social state progresses. The true social state progresses even if we have no computational representation of it. But lacking an explicit meaning, each principal could interpret messages in incompatible ways. For example, in the healthcare setting, a laboratory may interpret the messages with the claim information as leading to an unconditional commitment from the MCO to honor the claim. The MCO, however, may interpret the commitment as being conditional on the claim being valid. Such misalignments could have serious repercussions for the principals (e.g., in producing their balance sheets) and may lead to legal disputes. If the principals negotiate the meanings of the messages and hard-code them in their information systems, they would produce hidden couplings among themselves: changes in how one principal handles messages would need to be propagated to the others. Additionally, explicit social meaning promotes accountability because if the meanings are public, then principals can potentially check the compliance of themselves and others. Solely Social Meaning A system specification must specify only the possible communications and their meanings and nothing else. Further, the meaning must be expressed in terms of social abstractions such as commitments. Specifications of any operational details that have significance at the social level (e.g., a convention to pay first), must be captured via social abstractions (e.g., commitments). Specifications that capture ordering and occurrence constraints separately from the meaning violate this principle. For example, one could specify in the appointment scheduling protocol that availableSlots follow requestAppointment. But here no one is accountable for the constraint: is the physician at fault for not delaying sending availableSlots or is the patient at fault for not sending requestAppointment? Instead, if this constraint is necessary as a social requirement, one or more of Interaction-Oriented Software Engineering A:11 the principals should commit to enforcing it, e.g., adopting Marengo et al.’s [2011] approach and placing temporal constraints in commitments. Further, specifying the technical infrastructure does not capture a sociotechnical system. We might either model the social actor who provides the infrastructure and engage it via commitments or omit such technical constraints altogether since they apply at a lower level of abstraction. Example. The above ordering constraint can be expressed [Marengo et al. 2011] as C(PHY, PAT,⊤, requestAppointment · availableSlots) where the dot (‘·’) means occurs before. Benefit. Promotes autonomy and accountability. No central controller enforces constraints in a sociotechnical system. Every constraint logically ought to be some principal’s responsibility. Expressing a constraint as a hard constraint to be enforced magically by the environment either underspecifies the functioning of the system or (in most current thinking) postulates a central entity that is the sole autonomous principal and can impose its will upon all the other participants. 5.3. Separation of Social and Technical Concerns Separation of concerns refers to the treatment of each aspect of a problem independently of yet in relation to others. It refers to the sorting out of the different threads from what would otherwise be a tangled mess. Often, the invocation of this principle is implicit. For example, Zave and Jackson’s identification of domain assumptions, machine requirements, and user requirements as the separate but essential categories for RE is at its heart an application of this principle. Dardenne et al. [1993] and Yu [1997] express early requirements in the form of goal models, thus separating the exploration of the problem space from the solution space. Mylopoulos et al. [1992] separate nonfunctional from functional requirements. Finkelstein et al. [1992] separate concerns explicitly based on stakeholders, acknowledging the fact that, in general, each stakeholder has different concerns and may employ different representations for expressing them. For sociotechnical systems, we must separate social and technical considerations. Principals such as people and organizations must be distinguished from technical entities such as resources, legacy systems, software components, devices, communication infrastructure, and other technical objects in the environment. This is because social relationships are meaningful only among principals. A principal may only bear a control relationship (e.g., ownership, invocation, or access) toward a technical entity as may one such entity toward another. Only principals are autonomous and accountable: a patient cannot sue an operating table but can sue a surgeon or a hospital. Example. As Figure 4 shows, Alessia and Bianca maintain a social relationship. However, each of them maintains and controls an information system, which is not socially visible. Benefit. Separating the social and technical entities makes clear the kinds of relationships that would make sense among them. Promotes accountability by making clear only principals are accountable to each other in the social sense. Enables engineers of sociotechnical systems to focus solely on the social aspects. 5.4. Encapsulation: No Principal Internals Encapsulation refers to the principle that a module reveal no more information than is necessary to effectively use it, in particular, that it reveal no implementation details. Figure 2 highlights the interface between the machine and the environment but does not bind the machine to any particular internal implementation. Zave and Jackson [1997] characterize RE as the process by which you arrive at the machine-environment interface; anything more would amount to prematurely determining an implementation. In i* and Tropos, dependencies among actors correspond to their interfaces. The idea of encapsulation, namely, to avoid examining the internals of a component, remains appropriate in IOSE. A direct consequence of this principle is that a sociotechnical system cannot be specified in terms of mental abstractions such as beliefs, goals, intentions, and so on—neither of its stakeholders nor of the principals who may participate in it. In particular, roles cannot be specified in terms of mental abstractions. In IOSE, each role in a protocol refers only to the social commitments resulting from the communications that a principal adopting it would be involved in. A:12 Chopra and Singh Example. Neither the PHY role nor the PAT role has goal of scheduling appointment; neither do they have a shared (joint) goal to schedule appointments. Benefit. Promotes loose coupling by hiding details not relevant to the interaction. Also promotes accountability: a key reason we cannot use mental concepts to specify a sociotechnical system is that they make determining compliance impossible [Singh 1998]. As mentioned earlier, accountability is meaningless if we cannot check compliance. 5.5. Summary of Principles Table III presents the principles and their benefits at a glance. Table III: IOSE principles for sociotechnical system specification and their benefits. Principle Interpretation Benefits Promoted Accountability modularity Principals are the basic units of autonomy and, therefore, modularity. Principals are accountable for their communications and the resulting social expectations, e.g., commitments. Autonomy and accountability Explicit social meaning The social meaning of communication should be made explicit in system specifications. Accountability and loose coupling. Solely social meaning Specify only communications and their social meaning, not control flow or other kinds of low-level constraints Autonomy and accountability. Separating social from technical Social relationships hold among principals, not among principals and technical components and neither among technical components Modeling perspicuity and accountability. No principal internals System specifications should not refer to the internals of principals Accountability and loose coupling. 6. COMPARING IOSE WITH PROMINENT SE METHODOLOGIES We now evaluate IOSE with some prominent approaches from SE. We choose these either because (1) they are representative of broad classes of approaches for modeling sociotechnical systems (i*, Tropos, KAOS), or (2) they give emphasis to interaction and protocols (Gaia and Choreographies).